Skip Headers

Oracle® Database Installation Guide 10g Release 2 (10.2) for hp-ux Itanium Part Number B25293-01 |
Home | Book List | Contents | Index | Master Index | Feedback

Previous | Next
| View PDF

# D Optimal Flexible Architecture

This appendix describes the Optimal Flexible Architecture standard. The standard is a set of configuration guidelines created to ensure reliable Oracle installations that require little maintenance. It includes information about the following topics:

- Overview of the Optimal Flexible Architecture Standard

- Changes to the Optimal Flexible Architecture for Oracle Database 10g

- Implementing Optimal Flexible Architecture

- Improving Reliability and Performance

## D.1 Overview of the Optimal Flexible Architecture Standard

The Optimal Flexible Architecture standard is designed to:

- Organize large amounts of complicated software and data on disk, to avoid device bottlenecks and poor performance

- Facilitate routine administrative tasks such as software and data backup, which are often vulnerable to data corruption

- Facilitate switching between multiple Oracle databases

- Adequately manage and administer database growth

- Help eliminate fragmentation of free space in the data dictionary, isolate other fragmentation, and minimize resource contention

Optimal Flexible Architecture is a set of guidelines that you should adopt when organizing Oracle directories and files on your computer. All Oracle components on the installation media are compliant with Optimal Flexible Architecture. This means that Oracle Universal Installer places Oracle Database components in directory locations that follow Optimal Flexible Architecture guidelines.

Although using Optimal Flexible Architecture is not a requirement, Oracle recommends that you use it if your database will grow in size, or if you plan to have multiple databases.

### D.1.1 Characteristics of an Optimal Flexible Architecture Compliant Installation

The following are the characteristics of an Oracle product installation that complies with the Optimal Flexible Architecture standard:

- File system organization

  The file system is organized to enable easy administration and to facilitate:

  - Adding data into existing databases

  - Adding users

  - Creating databases

  - Adding hardware

- Distributed I/O loads

  I/O loads are distributed across enough disk drives to prevent performance bottlenecks.

- Hardware support

  In most cases, you do not require new hardware to implement the Optimal Flexible Architecture standard.

- Safeguards Against Drive Failures

  By distributing applications across more than one drive, drive failures affect as few applications as possible.

- Distribution of Oracle home directories

  The following items can be distributed across more than one disk drive:

  - The collection of home directories

  - The contents of an individual home directory

- Integrity of login home directories

  You can add, move, or delete login home directories without having to revise programs that refer to them.

- Independence of UNIX directory subtrees

  Categories of files are separated into independent UNIX directory subtrees so that files in one category are minimally affected by operations on files in other categories.

- Supports concurrent execution of application software

  You can run multiple versions of Oracle software simultaneously, enabling you to test and use a new release before retiring the previous release. Transferring to a new release after an upgrade is simple for the administrator and transparent for the user.

- Separates administrative information for each database

  The ability to separate administrative information for each database ensures a reasonable structure for the organization and storage of administrative data.

- Uses consistent database file naming

  Database files are named so that:

  - Database files are easy to distinguish from other files

  - Files belonging to one database are easy to distinguish from files that belong to another database

  - Control files, redo log files, and data files can be identified as such

  - The association of data file to tablespace is clearly indicated

- Separation of tablespace contents

  Tablespace contents are separated to:

  - Minimize tablespace free space fragmentation

  - Minimize I/O request contention

  - Maximize administrative flexibility

- I/O loads tuned across all drives

  I/O loads are tuned across all drives, including drives storing Oracle data in either Automatic Storage Management disk groups or in raw devices.

## D.2 Changes to the Optimal Flexible Architecture for Oracle Database 10g

For previous releases of Oracle Database, the Optimal Flexible Architecture standard recommended Oracle home path was similar to the following:

    /u01/app/oracle/product/9.2.0

For Oracle Database 10g, the Optimal Flexible Architecture recommended Oracle home path has changed. The Optimal Flexible Architecture recommended path is now similar to the following:

    /u01/app/oracle/product/10.2.0/type[_n]

In this example, `type` is the type of Oracle home, for example Oracle Database (`db`) or Oracle Client (`client`), and `n` is an optional counter. This syntax provides the following benefits:

- You can install different products with the same release number in the same Oracle base directory, for example:

      /u01/app/oracle/product/10.2.0/db_1
      /u01/app/oracle/product/10.2.0/client_1

- You can install the same product more than once in the same Oracle base directory, for example:

      /u01/app/oracle/product/10.2.0/db_1
      /u01/app/oracle/product/10.2.0/db_2

## D.3 Implementing Optimal Flexible Architecture

This section describes the naming strategy recommended by the Optimal Flexible Architecture standard. It contains the following sections:

- File Systems

- Naming Directories

- Naming Database Files

- Separating Segments with Different Requirements

- Naming Tablespaces

- Exploiting the Optimal Flexible Architecture Structure for Oracle Files

- Optimal Flexible Architecture File Mapping

### D.3.1 File Systems

This section describes the conventions for mount points.

#### D.3.1.1 Number of File Systems

To fully implement the Optimal Flexible Architecture recommendations for a database stored on file systems that are not striped or mirrored, you require at least three file systems located on separate physical devices.

#### D.3.1.2 Naming Conventions

Name all file system mount points using the syntax `/``pm`, where `p` is a string constant and `m` is a unique fixed-length key (typically a two-digit number) used to distinguish each mount point. For example: `/u01` and `/u02`, or `/disk01` and `/disk02`.

#### D.3.1.3 Naming Mount Points for Very Large Databases (VLDBs)

If each disk drive contains database files from one application and there are enough drives for each database to prevent I/O bottlenecks, use the syntax `/``pm``/``q``/``dm` for naming mount points. Table D-1 describes the variables used in this syntax.

Table D-1 Syntax for Naming Mount Points for Very Large Databases

Variable | Description
--- | ---
`pm` | A mount point name
`q` | A string denoting that Oracle data is stored in this directory, for example, `oradata`
`dm` | The value of the initialization parameter DB_NAME (typically the same as the instance SID for single-instance databases)

For example, to allocate two drives exclusively for the `test` database, name the mount points `/u01/oradata/test` and `/u02/oradata/test`.

### D.3.2 Naming Directories

This section describes the naming conventions for directories that are compliant with the Optimal Flexible Architecture standard.

#### D.3.2.1 Oracle Base Directory Naming Convention

The Oracle base directory is the top-level directory for Oracle products installed by the same user. Name Oracle base directories using the syntax `/``pm``/``h``/``u`. Table D-2 describes the variables used in this syntax.

Table D-2 Syntax for Naming Oracle Base Directories

Variable | Description
--- | ---
`pm` | A mount point name
`h` | A standard directory name
`u` | The name of the owner of the directory (the user running Oracle Universal Installer)

For example, `/u01/app/oracle` is an Oracle base directory created by the `oracle` user and `/u01/app/applmgr` is an Oracle base directory created by the `applmgr` user.

Placing Oracle base directories at the same level in the UNIX file system is advantageous because it enables you to refer to the collection of Oracle base directories on different mount points using a single pattern matching string, `/*/app/*`.

#### D.3.2.2 Referring to Path Names

Refer to explicit path names only in files designed specifically to store them, such as the password file, `/etc/passwd`, and the Oracle `oratab` file. Refer to group memberships only in the `/etc/group` file.

#### D.3.2.3 Oracle Home Directory Naming Convention

To help fulfill the Optimal Flexible Architecture requirement of simultaneously running multiple versions of Oracle software, install the software in a directory matching the pattern `/``pm``/``h``/``u``/product/``v``/``type``_[``n``]`.

Table D-3 describes the variables used in this syntax.

Table D-3 Syntax for Naming Oracle Home Directories

Variable | Description
--- | ---
`pm` | A mount point name
`h` | A standard directory name
`u` | The name of the owner of the directory
`v` | The version of the software
`type` | The type of installation, for example Database (`db`), Client (`client`), Companion (`companion`), or CRS (`crs`)
`n` | An optional counter, which enables you to install the same product more than once in the same Oracle base directory

For example:

- `/u01/app/oracle/product/10.2.0/db_1` indicates the Oracle home directory for the first installation of Oracle Database on this system.

- `/u01/app/oracle/product/10.2.0/crs` indicates the Oracle home directory for Oracle Clusterware (Clusterware is required for RAC installations).

  Oracle Clusterware can be installed only once on the system, so the optional counter is not required.

Set the `ORACLE_HOME` environment variable after installation to specify the Oracle home directory.

#### D.3.2.4 Naming Subdirectories

To facilitate the organization of administrative data, Oracle recommends that you store database-specific administration files in subdirectories matching the pattern `/``h``/admin/``d``/``a``/`, where `h` is the Oracle base directory, `d` is the database name (DB_NAME), and `a` is a subdirectory for specific types of database administration files. Table D-4 describes the database administration file subdirectories.

Table D-4 Subdirectories for Database Administration Files

Subdirectory | Description
--- | ---
`adhoc` | Ad hoc SQL scripts
`arch` | Archived redo log files
`adump` | Audit files (Set the `AUDIT_FILE_DEST` initialization parameter to specify the `adump` directory. Clean out this subdirectory periodically.)
`bdump` | Background process trace files
`cdump` | Core dump files
`create` | Scripts used to create the database
`exp` | Database export files
`logbook` | Files recording the status and history of the database
`pfile` | Instance parameter files
`udump` | User SQL trace files

For example, `/u01/app/oracle/admin/sab/adhoc/` is the `adhoc` subdirectory associated with the database named `sab`.

### D.3.3 Naming Database Files

The following table lists the recommended file naming conventions for database files:

Note: Oracle Managed Files (OMF) and files stored in Automatic Storage Management disk groups use different naming conventions. For more information about these naming conventions, refer to the Oracle Database Administrator's Guide.

File Type | File Naming Convention
--- | ---
Control files | `/``pm``/``q``/``d``/control.ctl`
Redo log files | `/``pm``/``q``/``d``/redo` `n``.log`
Data files | `/``pm``/``q``/``d``/``tn``.dbf`

The following table describes this syntax:

Variable | Description
--- | ---
`pm` | A mount point name described previously in this appendix
`q` | A string (typically `oradata`) distinguishing Oracle data from all other files
`d` | The value of the DB_NAME initialization parameter (typically, the same as the instance SID for single-instance databases)
`t` | An Oracle tablespace name
`n` | A two-digit string

Note: Do not store files other than control files, redo log files, or data files associated with database `d` in the path `/``pm``/``q``/``d`.

Using this convention, it is easy to determine the database to which the `/u03/oradata/sab/system01.dbf` file belongs.

### D.3.4 Separating Segments with Different Requirements

Separate groups of segments with different lifespans, I/O request demands, and backup frequencies across different tablespaces.

Table D-5 describes the special tablespaces that the Database Configuration Assistant creates for each Oracle database. If you manually create a database, you must create the required tablespaces. These tablespaces are in addition to those required for application segments.

See Also: Oracle Database Administrator's Guide for information about creating databases manually

Table D-5 Special Tablespaces

Tablespace | Required | Description
--- | --- | ---
EXAMPLE | No | The EXAMPLE tablespace used to store the Sample Schemas
SYSAUX | Yes | Auxiliary tablespace to the SYSTEM tablespace
SYSTEM | Yes | Data dictionary segments
TEMP | Yes | Temporary segments
UNDOTBS1 | Yes | Used by Oracle to store undo information
USERS | No | Miscellaneous user segments

Creating these special tablespaces is effective because data dictionary segments are never dropped, and no other segments that can be dropped are allowed in the SYSTEM tablespace. Doing this ensures that the SYSTEM tablespace does not require a rebuild due to tablespace free-space fragmentation.

### D.3.5 Naming Tablespaces

Name tablespaces descriptively using a maximum of eight characters. Although Oracle Database tablespace names can be 30 characters long, portable UNIX file names are restricted to 14 characters. The recommended standard for a data file basename is `tn``.dbf`, where `t` is a descriptive tablespace name and `n` is a two-digit string. Because the extension and the two-digit string take six characters, only eight characters remain for the tablespace name.

Descriptive names enable the data file to be associated with the tablespace that uses it. For example, the names GLD and GLX might be used for the tablespaces storing General Ledger data and General Ledger indexes, respectively.

Note: Do not embed reminders of the word "tablespace" in your tablespace names. Tablespace names can be distinguished by context. For example, do not name the General Ledger tablespace `GLD_TBS01.dbf`.

### D.3.6 Exploiting the Optimal Flexible Architecture Structure for Oracle Files

Table D-6 describes the syntax used for identifying classes of files.

Table D-6 Directory Structure Syntax for Identifying Classes of Files

Directory Structure Syntax | Description
--- | ---
`/u[0-9][0-9]` | User data directories
`/*/home/*` | User home directories
`/*/app/*` | User application software directories
`/*/app/applmgr` | Oracle applications software subtrees
`/*/app/oracle/product` | Oracle software subtrees
`/*/app/oracle/product/10.2.0` | Oracle software subtree for release 10.2.0 products
`/*/app/oracle/product/10.2.0/db*` | Oracle home directories for Oracle Database 10g
`/*/app/oracle/admin/sab` | `sab` database administrative subtrees
`/*/app/oracle/admin/sab/arch/*` | `sab` database archived log files
`/*/oradata` | Oracle data directories
`/*/oradata/sab/*` | `sab` database files
`/*/oradata/sab/*.log` | `sab` database redo log files

### D.3.7 Optimal Flexible Architecture File Mapping

Table D-7 shows a hierarchical file mapping of a sample Optimal Flexible Architecture-compliant installation with two Oracle home directories and two databases. The database files are distributed across three mount points, `/u02`, `/u03`, and `/u04`.

Table D-7 Hierarchical File Mapping for an Optimal Flexible Architecture Installation

Directory | Description
--- | ---
`/` | Root directory
`/u01/` | User data mount point 1
`/u01/app/` | Subtree for application software
`/u01/app/oracle/` | Oracle Base directory
`/u01/app/oracle/admin/` | Subtree for database administration files
`/u01/app/oracle/admin/TAR` | Subtree for support log files
`/u01/app/oracle/admin/``db_name1``/` | `admin` subtree for db_name1 database
`/u01/app/oracle/admin/``db_name2``/` | `admin` subtree for db_name2 database
`/u01/app/oracle/doc/` | Online documentation
`/u01/app/oracle/flash_recovery_area/` | Subtree for recovery files
`/u01/app/oracle/flash_recovery_area/``db_name1` | Recovery files for db_name1 database
`/u01/app/oracle/flash_recovery_area/``db_name2` | Recovery files for db_name2 database
`/u01/app/oracle/product/` | Distribution files
`/u01/app/oracle/product/9.2.0` | Oracle home directory for Oracle9i release 2 (9.2.0)
`/u01/app/oracle/product/10.2.0/db_1` | Oracle home directory for Oracle Database 10g release 2 (10.2)
`/u01/app/kjf/` | Oracle base directory for user `kjf`
`/u01/app/edm/` | Oracle base directory for user `edm`
`/u02` | User data mount point 2
`/u02/oradata/` | Subtree for Oracle data
`/u02/oradata/``db_name1``/` | Subtree for db_name1 database files
`/u02/oradata/``db_name2``/` | Subtree for db_name2 database files
`/u03/` | User data mount point 3
`/u03/oradata/` | Subtree for Oracle data
`/u03/oradata/``db_name1``/` | Subtree for db_name1 database files
`/u03/oradata/``db_name2``/` | Subtree for db_name2 database files
`/u04/` | User data mount point 4
`/u04/oradata/` | Subtree for Oracle data
`/u04/oradata/``db_name1``/` | Subtree for db_name1 database files
`/u04/oradata/``db_name2``/` | Subtree for db_name2 database files

## D.4 Improving Reliability and Performance

One of the goals of Optimal Flexible Architecture is to improve reliability and performance by distributing I/O loads across different physical drives. The following are methods to accomplish this:

- Disk Mirroring

- Disk Striping

### D.4.1 Disk Mirroring

You can separate and treat Oracle Database log files and database files with different levels of hardware reliability. Oracle Database log files are highly reliable to start with, because they are stored redundantly. Creating similar reliability for database files may require you to duplicate all of your data, using disk mirrors.

Disk mirroring usually involves two or more identical drives and a RAID controller. If one disk fails, then the other disks can recover data that would otherwise be lost. Using one of the disks to recover lost data may involve losing the mirror. If this happens, then you must build a new mirror.

Disk mirroring is part of some levels of Redundant Array of Independent Disks (RAID) configurations, provided by the disk controller. The RAID level determines the amount of redundancy. Some RAID levels can use the hot swapping feature, which means that you can replace a bad disk with a good one without turning off the computer or losing functionality.

### D.4.2 Disk Striping

How you set up disks for use in a database depends on the number of disks and the type of hard disk controllers available. If the hard disk controllers support both striping and mirroring, then Oracle recommends that you configure the controllers to support striping.

Striping provides significant performance advantages. All the space from the striped drives appears as a single logical drive. In addition, the space is used by interlacing stripes of space from all of the disks in the stripe. This means that a large file uses some space from the first disk, then some from the second disk, and so on to the last disk, and then starting back at the first disk again. Each file can be spread over all of the striped disks. Multiple CPUs can access data randomly in such a file without contention.

Controllers that support striping usually provide caching as well. This means that data can be written to the controller and cached and saved for a time in storage not on the disk. Data that is read can be cached on the controller in the same manner. Read caching should not be used with Oracle Database, because all database reads are already cached in the System Global Area (SGA). The value of the `DB_CACHE_SIZE` parameter in the initialization parameter file, `init.ora`, determines the buffer size that can be used in the SGA. This value also configures Oracle Database on startup.

Note: Read caching should be disabled. Disk write caching should be disabled on disks containing Oracle Database data files and redo log files where the contents of the write cache are not flushed to disk in the event of a power failure or operating system failure. Consult your vendor documentation for more information.